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Jh , Abstract. We consider the interpretations of notions of access control (permis- 

*^' sions, interdictions, obligations, and user rights) as run-time properties of infor- 

■^l>( , mation systems specified as event systems with fairness. We give proof rules 

for verifying that an access control policy is enforced in a system, and consider 
fvj ' preservation of access control by refinement of event systems. In particular, re- 

finement of user rights is non-trivial; we propose to combine low-level user rights 
and system obligations to implement high-level user rights. 



1 Introduction 



The specification of access control policies for information systems is a fundamental 
building block of a methodology for describing and assessing the security of informa- 
tion infrastructure. Existing languages for describing access control such as RBAC L221 
and OrBAC 1171 focus on the static structure of information systems. They identify 
the actors (abstractly represented as roles), objects (abstracted as views), and activi- 
ties that intervene in an information system, and then impose constraints on activities, 
^S ' in the form of permissions and prohibitions. Certain formalisms also encompass more 

\^ . advanced security properties such as rights or obligations of actors to perform certain 

^D ' activities. OrBAC makes a step toward specifying access control policies that may de- 

c/5 . pend on run-time information by associating rights with contexts. However, it is not 

J-^ ' possible within OrBAC to verify that a system enforces a given access control policy, 

because the dynamic behavior of the system is not modeled. 

In this paper, we propose to relate the specification of access control pohcies to 

formal models of dynamic system behavior, and we give proof rules to demonstrate that 

C^ ' a system implements an access control policy. Changing somewhat the perspective, one 

can also pose the problem of deriving a security monitor that enforces a policy for a 
fixed, underlying system. 

We describe information systems within the well-known paradigm of event systems, 
see e.g. I2I3I7I . Run-time properties of event systems can be specified as formulas of 
temporal logic, and there are well-established verification rules to derive properties of 
event systems. We are therefore led to interpret access control primitives as properties of 
runs of event systems: permissions and prohibitions are easily expressed as constraints 
on the enabling condition of events. Dually, the right of an actor to perform a certain 
activity can be expressed as a lower bound on the enabling condition. The interpretation 

* This work was partly supported by the project Desirs of ACI Securite Informatique. 



of obligations is less obvious, and we propose to interpret them as liveness properties, 
expressible in temporal logic. 

Event systems have traditionally been associated with a formal development method 
based on stepwise refinement. We therefore consider how access control annotations are 
preserved under system refinement. Because permissions, prohibitions, and obligations 
are interpreted as safety and liveness properties of runs, standard results about refine- 
ment of event systems ensure that they are preserved by refinement. Preservation of 
user rights requires extra conditions, and the precise formulation is non-trivial when the 
"grain of atomicity" of a system description changes during refinement. We propose a 
condition that relies on a combination of concrete-level user rights and obligations. We 
illustrate our proposals with a running example of a simple loan management system 
on which different access control requirements can be imposed. 

Related work. The existing literature on formalisms for the specification of access con- 
trol considers mainly static methods of analysis. For example, Bertino et al. flO] and 
Cuppens et al. fTlll . among others, analyze security policies for inconsistencies, and 
Benferhat et al. (9) consider techniques to resolve such inconsistencies based on strati- 
fication of rules. 

Closer to our concerns is work by Ryan et al. 1 131231 on the use of model check- 
ing for verifying access-control policies. However, we work in a deductive framework, 
and we are mainly interested in verifying refinement relationships. Koch et al. [181 sug- 
gest a UML notation for specifying access control, together with a semantics based on 
graph transformation and corresponding analysis techniques. More distantly related is 
the work around UMLSec 1 161, which is mainly concerned with secrecy properties. In 
particular, Jiirjens L15J considers the preservation of secrecy properties by the refine- 
ment concepts of the specification language Focus. 

2 Fair Event Systems 

We use the well-known paradigm of event systems I2I3I7I . extended by weak fairness 
conditions, to express system models.' This section gives a brief overview over the 
syntax we use to describe systems and their properties, and introduces associated veri- 
fication rules. 



2.1 Event systems and their runs 

A system specification lists the constant parameters, including any underlying sets, 
functions, and relations that describe the data over which the system operates. A con- 
stant assumption Hyp constrains the values of these constants; it is syntactically ex- 
pressed as a first-order logic formula over the constant parameters. 

More importantly, a specification declares a tuple var of state variables that repre- 
sent the current state of the system. The runs of a system are characterized by an initial 



' Adding strong fairness would not pose any conceptual problems, but it would complicate the 
presentation because we would have to introduce more elaborate temporal logic operators. 



condition, which is a state predicate Init over the variables var, and a list of events that 
describe the possible system transitions. We write the definition of an event e, with list 
of parameters x, as 

event e{x) = BAe{x, var, var') 
fairness /a ;>(. {x, var) 

In such a definition, BAg is the before-after predicate for the event e; this is a first-order 
formula built from the constants declared for the system specification, the event's pa- 
rameters X, as well as primed and unprimed occurrences of the system variables var. As 
is conventional, a primed occurrence v' of a state variable v denotes the value of v in the 
state following the transition described by BA^, while an unprimed occurrence denotes 
the value of v in the state before the transition. Each event is associated with a fairness 
condition, expressed by a predicate /a/rg(jc, var). Intuitively, the fairness condition rules 
out traces where the predicate /a/rg(ji:, var) remains true but the event e{x) never occurs. 
For an event e{x), we define its feasibility condition 

fise(x) = 3var : BAe{x,var,var) (1) 

by existentially quantifying over the primed occurrences of the state variables; thus, the 
state predicate flse(x) is true of those states that have a successor state related by an 
occurrence of the event e{x). 

Finally, a system specification should provide an invariant that constrains the set of 
reachable states, syntactically specified by a state predicate Inv over the system variables 
var. 

A system specification is well-formed if all of the following conditions hold: 

- The initial condition implies the invariant: 

Hyp \= Init{var) =^ Inv{var) (2) 

- The invariant is preserved by any event e, for any instantiation of the parameters: 

Hyp \=: Inv(var) /\BAe{x,var,var') ^ Inv{var') (3) 

- For any event, the fairness condition implies the feasibility of the event: 

Hyp \= Inv{var) f\faire{x,var) ^^se{x) (4) 

Observe that we allow the fairness condition to be strictly stronger than the feasi- 
bility predicate. For example, an event without fairness assumption can be modeled 
by declaring the fairness condition to be false. 

In the following, we simplify the notation by writing P and P' for P{var) and P{var') 
when P is a state predicate and A{x) fox A(x,var, var') when A is a formula that con- 
tains both primed and unprimed occurrences of state variables, such as a before-after 
predicate. 



system Bank 

constants Client, Loan, maxDebt 

assumption Client 7^ A Loan 7^ A maxDebt e Q 

variables clt, loans, due, rate, maxExtra, extra 

Invariant A loans C Loan 

A clt e [loans — * Client] A due e [loans ^ Q] A rate £ [loans -^ Q] 
A maxExtra e [loans -^ Q] A extra e [loans -^ Q] 
A Vc £ C/ie«f : {Y,{due{ll) : II e loans A clt {II) = c}) < maxDebt 
Initial loans = <dAclt = @A due = A rate = A maxExtra = A ex?ra = 
event newLoan{c, I, amt, dur, mx) = 

A c G Client A I £ Loan \ loans A amt G Q A dur G N 
A amt+ [Y,{due{ll) : // £ loans Aclt{ll) = c}) < maxDebt 
A loans' = loans U {/} A c/f' = c/f U {/ 1-> c} 
A due' = due U {/ 1— » sum^ A rate' = rate U {/ 1— > sum/ dur} 
A maxExtra' = maxExtra U {/ 1-^ mx} A extra' = extra U {/ h^ 0} 
fairness false 

e\ent pay Rate (l) = 

A / e loans 

A due' = due ®{li-^ due{l) — rate(T)} 

A loans' = loans A clt' = clt A rate' = rate A maxExtra' = maxExtra A extra' = extra 
fairness I e loans Adue{l) > 

event extraPayBack{l, amt) = 
A / G loans A amt £ Q 

A due' = due © {/ 1— » due(l) — amt} A extra' = extra © {/ ^-> extra(l) + amt} 
A loans' = loans A clt' = clt A rate' = rate A maxExtra' = maxExtra 

fairness false 
end system 

Fig. 1. Sample system specification. 

Figure^shows a specification of a simple event system that will serve as a running 
example for this paper^. It models a simple management system for loans: clients can 
take out loans provided they are not overly indebted, and they should pay them back, 
either by paying the rates due or via extra payments. The specification is written in a 
language of set theory where functions are sets of pairs x h-> y and where © denotes 
function override. It is easy to verify that this specification is well-formed according to 
the above criteria. At this point, we only give the model of the base information system, 
it will later be extended with annotations corresponding to access control primitives. 

Runs of a system specification are co-sequences o = sqsi . . . of states (i.e., valuations 
of variables) that satisfy the following conditions: 

- the initial state sq satisfies the initial condition, 

- any two successive states (s,-,i,+i) either satisfy the before-after predicate BAe{x) 
for some event e and some parameter values x, or agree on the values of all system 
variables var (so-called stuttering steps), and 



^ We adopt the convention of writing long conjunctions and disjunctions as "lists" buUeted with 
A and V, relying on indentation to save parentheses. 



P A fiA„ (x) => P' for all events e (x) 

-^ ^— (stable) 

stable P 

Init^P stable P invP P => 2 

(induct) (inv-weaken) 

invP in\Q 

P A BAa (x) A -^BAe {t)^P'yQ' for all events a{x) 
P^fairejt) 

P-*ev(PAeW) 

Vx £ 5 : F(x) ^ G V (3.y £ 5 : .y ^ X A F(y) ) (5, ^ ) well-founded 
(3xe5:F(x))-^G 



(fair) 

(wfo) 



^^ ^- (effect) (refl) (inv-leadsto) 

PAe(r)-+e F-^G F-^GM 

G G~^ H F -^ H G -^ H F(x] -^ G{x) 

(trans) (disj) —'■ —'■ (exists) 



F^H FWG-^H (3x:F(x))-» (3x:G(x)) 

Fig. 2. Verification rules for fair event systems. 



- o satisfies all fairness conditions: for each event e and all parameter values x there 
are infinitely many positions ; G N such that either the fairness condition/fl;>g(x) is 
false at Si or (5,-,i,+i) satisfy BAj.(x). 

The well-formedness conditions (|3 and (|3j above ensure that each state Sj of a 
system run satisfies the system invariant. If only countably many event instances are 
feasible at each state of a system run, the condition © implies that the specification 
is machine-closed Q], but this observation will not play a role in the remainder of this 
paper. 

2.2 Properties of runs 

We can reason about the runs of fair event systems using elementary temporal logic. 
For the purposes of this paper, we consider safety properties stableP and invP where 
P is a state predicate, and liveness properties F -^ G {"F leads to G") where F and G 
are Boolean combinations of state predicates and event formulas e{x) for events e of 
the underlying event system. These formulas are interpreted over a run o = .s^o^i ... as 
follows: 

O h stableP iff for all « G N, if o|„ |= P then a|,„ h P for all m>n 

ohinvP iff a|„ hPforallneN 

a \^ F -^ G iff for all « e N, if o|„ |= F then a\,„ \= G for some m>n 

In these definitions, a\„ \^ F means that formula F holds of the suffix of a from point 
n onwards: if F is a state predicate then it should be satisfied at state s„, if F is an event 
formula e{x) then the defining action formula BAe{x) should hold of the pair of states 



Figure 12 contains proof rules for deriving properties of fair event systems; simi- 
lar proof rules can be found, for example, in papers on the Unity 1211 or TLA 1191 
formalisms. As before, Init denotes the initial condition of the system specification, 
BAe{t) denotes the before-after predicate defining the event instance e(f), and faire{t) 
represents the fairness condition associated with that event instance. The variable x in 
rules (stable) and (fair) is assumed to be different from the free variables of P, Q or 

BAeit). 

The rule (fair) is the basic proof rule for establishing leadsto properties; its sound- 
ness relies on the underlying assumption of weak fairness. Rule (wfo) allows us to de- 
rive liveness properties by induction over some well-founded ordering. The remaining 
rules can be used to combine elementary leadsto formulas. In proving the non-temporal 
hypotheses of these rules, we may of course use any assumptions on the constants ap- 
pearing in a system specification. 



3 Specifying Access Control 

Access control policies describe the conditions under which events may occur. Typi- 
cally, one first specifies the actors (roles), objects (views), and activities of an informa- 
tion system, and then describes which actors are allowed to (or not allowed to) perform 
which activities on which objects. The OrBAC formalism (17| refines this general idea: 
first, access control policies are described within organisations (e.g., a hospital or a 
bank). Second, and more significantly, one can specify conditions under which an ac- 
cess is allowed by defining a "context" of access. Moreover, roles, views, and activities 
are arranged in hierarchies, with access rules for instances systematically derived with 
the help of inheritance rules 1121 . 

OrBAC thus provides a declarative, PROLOG-like language to define access control 
policies. The dynamic aspect of a system is captured by the notion of context, which 
can be defined in terms of the system state. It is straightforward to translate an OrBAC 
model into an event system: the static structure of roles and views is represented by the 
constant parameters of a system, activities correspond to the system's events, and con- 
texts are defined as state predicates. Without completely formalizing this translation, we 
now consider how event systems can be extended to describe access control policies.^ 
The interest in doing so can be twofold: first, an event system can be developed in order 
to verify that it satisfies a given policy. Second, one may be interested in enforcing an 
access control policy over a fixed underlying system by imposing a security monitor. 
We will consider both of these views for different access control primitives: permissions 
and prohibitions, user rights, and obligations. 



3.1 Permissions and prohibitions 

At its base, an access control policy describes when an activity is permitted, and when 
it is forbidden. Whereas permissions and prohibitions should be mutually exclusive. 



^ The running example of Fig.Qdoes not mention roles (actors), but it should be obvious how 
to include them in the static model. 



they need not cover all possible situations in cases where the policy is not completely 
specified. 

We represent permissions and prohibitions by associating two more predicates (be- 
sides the fairness predicate already introduced in Sect. 12. 1> with event definitions. For 
example, a security policy might specify 

event newLoan (c, Z, atnt, dur, mx) 

permission / ^ loans A risk(c,amt) 6 {low,mediutn} Atnx < maxPayback{amt,dur) 

prohibition risk{c, amt) = high 

to indicate that a new loan for a client may be approved if the associated risk (evaluated 
according to some unspecified risk function) is below a certain threshold value and if 
the maximum amount permitted for extra payback is within certain bounds, and that a 
new loan must not be approved if the risk is too high. 

An event system implements the permissions and prohibitions declared in a security 
policy if the event is feasible only if it is permitted and infeasible when it is forbidden. 
Formally, we obtain the proof obligations 

Hyp ^ /nvAflse(x) ^ penne(x) (5) 

Hyp 1= Inv hprohe{x) => -iflse(jc) (6) 

where perme{x) and prohe(x) are the permission and prohibition predicates associated 
with event e, and Inv and Hyp are the system invariant and the constant assumptions, as 
before. 

The event system of Fig.[l]does not implement the above permissions and prohibi- 
tions, as it does not evaluate the risk associated with a loan. A simple way of ensuring 
that a system implements the permission and prohibition clauses of a security policy 
is to conjoin perme{x) A ^prohe{x) to the before-after predicate of the event definition. 
Alternatively, the access control policy can be ensured at run time by a separate monitor 
that allows events to be activated only if the permissions and prohibitions are respected. 

Observe, however, that strengthening the guard of an event may invalidate the well- 
formedness condition @ that states that the fairness predicate of an event should imply 
its feasibility. We therefore add the following proof obligation to the well-formedness 
conditions of an event system with permissions and prohibitions: 

Hyp 1= Inv Afaire{x) ^ perm(,(x) A^prohgix). (7) 

This condition is trivially satisfied for the event newLoan of our running example, be- 
cause no fairness is required of that event. 

3.2 User rights 

Permissions and prohibitions restrict the feasibility of events. Dually, it may be interest- 
ing to specify user rights: conditions that spell out when an activity should be permitted 
in a system. User rights can again be represented in event systems by associating a cor- 
responding predicate with an event. For example, we may wish to state explicitly that a 
client has the right to make extra payments within the agreed-upon limits: 

event extraPayBack{l, amt) 

right I G loans A amt G Q A amt + extra (I) < maxExtra{l) . 



An event system implements a user right if the event is feasible whenever the pred- 
icate specifying the right holds: 

Hyp 1= Inv^ right e{x)^&se{x) (8) 

Because a security monitor can only schedule existing events of the underlying system, 
user rights will have to be verified over the event system itself rather than enforced by 
a monitor However, the monitor will have to observe a similar condition to make sure 
that an event permitted by a right is never disabled by the monitor. 

The conditions (|5|i, (|6|l, and (|8|i show that the right to perform an activity should 
imply (assuming the system invariant) that the activity is allowed, and that it is not 
forbidden. It is not unreasonable for a user right to be strictly stronger than the cor- 
responding permission, or than the feasibility of the event. For example, a bank may 
accept extra payments beyond the pre-determined bound at its discretion. 

User rights can be understood as branching-time properties: whenever the predi- 
cate right g [t) is true, the system has a possible continuation that begins with the event 
(instance) e{t), and we will take up this discussion in Sect. 14.21 

3.3 Obligations 

Languages for access control policies such as OrBAC also include primitives for spec- 
ifying obligations. Intuitively, whereas a user right states when a certain activity may 
occur, an obligation asserts that the activity should occur. The article II7I introducing 
the OrBAC notation does not define a formal semantics for obligations, but concepts 
of permission, rights, and obligations have traditionally been the domain of deontic 
logic 1 1 41201 . To our knowledge, the interpretation of formulas of deontic logic over 
models of information systems such as event systems has not been studied, and we do 
not wish to introduce this extra complication. 

As before, we associate obligations with events by defining suitable predicates. In 
our running example, we might want to assert that a user has an obligation to pay the 
rates as long as they are due by writing 

tytni payRate{l) 

obligation / G loans A due{l) > 0. 

What does it formally mean for an event system to implement an obligation? A first 
idea would be to interpret an obligation to perform a certain activity as prohibiting the 
system from performing any other activity. However, this interpretation appears to be 
unreasonably stringent and prone to contradictions. For example, a user of a computer 
system may have an obligation to regularly change his password, but he can do so only 
when logged in. Clearly, the obligation to change the password should not preclude the 
user from logging in, although it is conceivable that one could then prevent the user 
from doing anything but changing his password. 

We believe instead that obligations can, in a first approximation, be interpreted as 
liveness properties, and can be formalized in temporal logic. The two following inter- 
pretations appear particularly plausible. 

strict obhgation: oble{x) -^ e{x) (9) 



weak obligation: oble{x) -^ ^oblf.{x)\/ e{x) (10) 

The strict interpretation of obligations requires that the event occurs eventually 
whenever the obligation arises. Under the weak interpretation, the obligation ceases 
as soon as the predicate oblg becomes false, which need not be due to an occurrence of 
e. In our example, the weak interpretation appears more reasonable: it is satisfied when 
a client pays back the loan via an extra payment. Observe that the weak interpretation 
of an obligation coincides with the interpretation of a weak fairness requirement, with 
oble{x) as the fairness condition. 

Whatever interpretation is chosen, the proof rules of Fig. |2]can be used to verify 
that a fair event system implements its obligations. The temporal interpretation of obli- 
gations may also be of interest when one is interested in deriving a security monitor 
that enforces obligations for a given system, at least for controllable events. To do so, 
one could apply recent work on controller synthesis based on game-theoretic interpre- 
tations l6|, but we do not pursue this idea any further here. 

In some applications, the interpretation of obligations as liveness properties may be 
too abstract, and it would be more natural to indicate real-time deadlines for obligations 
("the payment should be received before the end of the current month"). We do not 
consider real-time specifications in this paper. 

4 Refinement of System Specifications 

Stepwise methods of system development insist that systems should be developed in 
a succession of models that gradually add representation detail and that introduce new 
correctness properties. The key requirement for a sensible notion of refinement is that 
system properties that have been established at higher levels of abstraction are preserved 
by construction so that they do not have to be reproven. Refinement-based approaches 
help to discover potential problems early on. They also distribute the overhead of for- 
mal verification over the entire development process. We will first consider verification 
conditions for proving refinement of fair event systems that preserve temporal logic 
properties. In a second step, we will study how refinement interacts with the access 
control primitives considered in Sect.|3] 

4.1 Refinement of fair event systems 

Standard refinement notions for event systems are known to preserve safety proper- 
ties, and extensions for liveness and fairness properties have also been considered, for 
example in 15181 . In the following, we make use of the language of temporal logic of 
Sect. l2.2l to state verification conditions for preserving liveness properties at a higher 
level of abstraction than in traditional formulations. 

Refined models describe the system at a finer level of granularity and typically in- 
troduce new events that have no observable effect at the previous levels of abstraction. 
Formally, we assume (without loss of generality) that the refinement is described with 
the help of a tuple varref of variables disjoint from the variables varabs used in the orig- 
inal model. The two state spaces are related by a gluing invariant J, a state predicate 



built from the variables varahs and var,-gf, and the constant parameters of both models. 
We may assume that J implies both the abstract-level and the concrete-level invariants 
Invaijs and Im'ref- An event ea{x) of the abstract model may be refined by a number of 
low-level events er\{x,y\), ... , er„{x,y„); for technical simplicity, we assume that all 
parameters of ea are also parameters of er,-, although this assumption could easily be 
removed. Also, new events en{z) may be introduced in the refined model. 

An event system Ref is a refinement of an event system Abs with respect to the 
gluing invariant J if Ref is itself well-formed according to the conditions (|2}, (|3}, and 
Q, and if moreover all the following conditions hold (again, we drop the variables that 
occur in the respective predicates; besides. Hyp denotes the conjunction of the abstract- 
and concrete-level constant assumptions). 

- Every initial state of the refinement can be mapped to a corresponding initial state 
of the abstract specification: 

Hyp \= Initref ^ ^varab., : InitahsAJ (H) 

- Events of the refinement can be mapped to events or to stuttering transitions of the 
abstract specification. There are two cases: 

• If event er{x,y) refines an abstract event ea{x) then its effect can be mapped to 
an occurrence of ea: 

Hyp h JABA,r{x,y) ^ 3var'^,,,^ : BA,,{x) AJ' (12) 



• 



If event en{z) is a new event then its effect is invisible at the abstract level : 

Hyp h J/\BA,„{z) =^ 3var[,^^ : var[,^^ = varahs AJ' (13) 

The refinement preserves the fairness constraints of the abstract level. Formally, 
assume that the abstract event ea{x) is refined by low-level events eri {x,y[), . . . , 
ern{x,yn): 

Ref ^ JAfaireaix) (14) 

•w ea 1 (x) V . . . V ea„ (x) V ^3vflr„/„ : J Afairea (x) 

where the "abstract trace" efl,(x) of er,(x,3',) is defined as 

eai{x) ^ Byr- Aer;(x,y,-) 

A yvarabsjVa/^i^^ : J AJ' ^ ea{x) 

Intuitively, condition (I14> requires to prove that any state in a run of the refinement 
that corresponds to a state satisfying the abstract fairness condition of event ea{x) 
is followed either by the occurrence of one of the refining actions or by a state that 
no longer satisfies the fairness condition. Although the formal statement is some- 
what technical, the abstract-level fairness condition is conveniently represented as 
a concrete-level "leads to" formula that can be established using the proof system 



'^ As suggested in 0|, this requirement could be weakened by requiring that event en{z) merely 
preserves the high-level invariant. 



of Fig. 13 In particular, any fairness conditions of the implementation may be used, 
as well as induction over well-founded orderings. In this way, a specifier has much 
more freedom in justifying a refinement than with the more traditional verification 
conditions of L5_ 



Using a standard simulation argument that critically relies on the possibility of stut- 
tering in the definition of runs of event systems, one obtains the following correctness 
theorem: every run of the refined event system Ref corresponds to a run of the abstract 
event system Abs, modulo the gluing invariant. 

Theorem 1. Assume that Ref is a refinement of Abs with respect to the gluing invariant 
J and that a — sqsi . . . is a run of Ref . Then there is a run T = toti . . . of Abs such that J 
holds at the joint valuations obtained from si and ti,for all i G N. 

As a consequence, temporal logic properties can be transferred from an abstract 
event system Abs to its refinement Ref modulo the gluing invariant J. Formally, this is 
asserted by the following corollary. 

Corollary 2. Assume that Ref is a refinement of Abs with respect to the gluing invariant 
J and that O = sqsi . . . is a run of Ref . If Abs ^ (p then Ref |= 0(p where 0(p is obtained 
from (p by replacing every positive occurrence of a non-temporal formula A by Bvar^bs '• 
J A A and every negative occurrence by ^varabs '■ J ^ A. 

4.2 Refinement preserving access control 

Let us now consider how refinement interacts with access control policies. Assume 
that event system Ref is a refinement of Abs with respect to the gluing invariant J. Also, 
assume that A/75 was known to implement certain permissions, prohibitions, obligations 
or user rights concerning an abstract event ea{x). 

For permissions permea (x) and prohibitions pro/jea(x), the conditions Q and (|6} 
ensure that permea{x) and -^prohea{x) hold whenever event ea{x) occurs in a run of 
Abs. Any concrete-level event er{x,y) refining ea{x) has to satisfy condition (I12> . Us- 
ing the definition of feasibility Q and first-order logic, it follows that 0permea{x) and 
0^prohga (x) hold whenever event er{x) occurs in a run of Ref . This is the best preserva- 
tion result we can hope for in such a general discussion of refinement modulo a gluing 
invariant; for most practical choices of J these formulas will imply that the abstract- 
level permissions and prohibitions are preserved in the refined system. 

Similarly, obligations have been interpreted as liveness properties, represented by 
the temporal logic formulas (|9j or ( JlOt . Corollary |2] implies that a similar "leads to" 
formula is true of the refined model, again modulo translation along the gluing invariant. 
Therefore, obligations are preserved in the same sense as permissions and prohibitions. 

These preservation results are not really surprising: we have interpreted permis- 
sions, prohibitions, and obligations as (safety or liveness) properties of runs, and the 
refinement notion of event systems are defined in such a way that properties of runs 
are preserved. However, we have also considered user rights, which were interpreted as 
branching properties in Sect. 13.21 and refinement of event systems does not necessarily 
preserve branching behavior. 



event askPayback{l, amt) = 

A / e loans A amt £ Q 

A askExtra' = askExtra U {/ 1-^ amt} 

A loans' = loans A c/f' = clt A rfue' = dwe A rate' = rate 

A maxExtra' = maxExtra A extra' = extra 
right Z e loans A amf £ Q 

event approvePayback{l, amt) = 

A (/ H- > amt) £ askExtra A amt + extra{l) < maxExtra{l) 

A rfwe' = rfwe ® {/ 1^ due{l) — amt} A exfra' = extra ®{l^-^ extraij) + amt} 

A askExtra' = askExtra \{l*-^ amt} 

A loans' = loans A c/f' = c7? A rate' = rate A maxExtra' = maxExtra 
fairness (/ 1-^ amt) e askExtra A amt + extra{l) < maxExtra{l) 

event rejectPayback(l, amt) = 

A (/ 1— > amt) £ askExtra A amt + extra{l) > maxExtra(l) 

A askExtra' = askExtra \{l*-^ amt} 

A rfwe' = due A extra' = extra 

A loans' = loans A clt' = clt A rate' = rate A maxExtra' = maxExtra 

Fig. 3. Refining event extraPayback. 



For a concrete example, consider a proposed refinement of the event extraPayback 
shown in Fig. |3] Instead of an atomic event modehng an extra payment, the refine- 
ment introduces a protocol: the client has to apply for making an extra payment (event 
askPayback), and this application can be approved or rejected by the bank, depending 
on the situation of the loan. The refinement is acceptable according to the conditions 
J12> and ( I13> because appwvePayback refines the abstract event extraPayback whereas 
the events askPayback and rejectPayback are unobservable at the abstract level. How- 
ever, the refinement does not literally preserve the user right 

event extraPayBack{l, amt) 

right / G loans A amt G Q A amt + extra{t) < maxExtra (/) . 

considered in Sect. 13.21 the concrete-level event approve Payback requires the precon- 
dition {I H^ amt) G askExtra, which is not implied by the predicate specifying the user 
right. Preservation of user rights thus requires extra consideration. 
A first idea would be to impose the condition 

Hyp \= Im'ref A0righteaix) ^ {3yi :Rseri{x,yi))\/ . . .V {3y„ :^sern{x,y„)) (15) 

where again eri(x,3'i), . . . , ern{x,y„) are the concrete-level events corresponding to the 
abstract event ea. Although condition (I15> obviously preserves user rights, it would 
rule out the refinement of Fig.|3 More generally, this condition appears too strong to 
us, when the concrete model refines the grain of atomicity. Recall that a single abstract- 
level event ea can be implemented in the refinement by a sequence of concrete-level 
events all but the last of which are invisible at the abstract level. The final event er 
refining the abstract event ea need not be immediately feasible in the concrete model 
whenever ea is, but it requires preparation by the auxiliary events that are unobservable 



at the abstract level. We therefore believe that a more useful condition for refining user 
rights is to require a combination of concrete-level user rights that ensure that the branch 
leading to er can be started and concrete-level obligations that ensure that er will then 
occur eventually. 

Formally, assume that the abstract system specification contains an event ea{x) for 
which we wish to ensure a user right via predicate rightea{x)- Also assume that ea{x) 
is refined by the concrete-level events er\{x,yi), .. . , ern{x,y„). We then require the 
event system Ref to contain events eii {x,Zi), . . . , eim{x,Zm) with user rights specified 
by righteij{x,Zj) such that 

0rightea{x) ^ (3zi : ng/jf(.,i(jc,zi)) V . . . V (3z,„ : riglitei,„{x,Zm)) and (16) 
eij{x,Zj) -^ -^0nghteaix) V {3yi : eri{x,yi)) V ... V (By,, : er„(jc,y„)) (17) 

Condition ill\ applies for ally = 1, . . . ,m; the disjunct -^0rightga{x) on the right- 
hand side of (I17> corresponds to a weak interpretation of obligations. 

The above conditions, together with the interpretations of the user rights for the 
refined specification, imply that whenever the translated abstract user right holds at 
some point during a concrete-level run, the user has a concrete-level right to start a 
branch which will eventually lead to the occurrence of an event refining the original 
event ea{x) provided the abstract-level right persists. For example, the abstract-level 
right may cease due to the concurrent exercise of another right. 

Back to the example of Fig.|3] we claim that this refinement respects the abstract- 
level user right because it satisfies the conditions (I16> and ( I17> . We assume that the 
gluing invariant contains the conjunct 

askExtra C loans x Q 

that asserts the "type correctness" of the new variable askExtra. We choose askPayback 
for the auxiliary event ei, and condition (I16> boils down to proving 

/ g loans A amt G Q A amt + extraQ) < maxExtra{l) => / G loans A amt G Q 

which is trivial. On the other hand, condition (I17> requires us to show 

askPayback{l,amt) ^^ V ^(/ G loans f\ amt G (J A a}nt + extra{l) < t7taxExtra(l)) 
V grantPaybackQ ,amt) 

and this condition is ensured by the fairness condition for event approvePayback. Note 
that although the abstract user right is preserved, the client cannot cheat on the bank by 
demanding two extra payments that together would exceed the allowed limit: although a 
client may always ask for an extra payment (including in the time between applying for 
a payment and the approval or rejection by the bank), the bank's obligation to approve 
extra payments ceases when the limit has been reached, so it is free to reject a second 
application for extra payments. This is just what the abstract user right of Sect. 13.21 
required. 



5 Conclusion 

Event systems are a convenient and widely accepted framework for modeling informa- 
tion systems. In particular, properties of their runs can be derived using well-known 
rules, and refinement concepts for event systems are well established. In this paper, we 
have considered annotating event systems with clauses to specify access control prop- 
erties, thereby implementing a given security policy. Existing, declarative languages for 
describing access control such as OrBAC identify the static structure of an information 
system, including the subjects, the objects, and the activities, and then spell out the con- 
ditions under which activities may, must, or must not be performed. In this paper, we 
have interpreted such policies within a formal system model based on event systems, 
and have proposed proof rules for verifying that a system implements a security policy. 
We have considered permissions and prohibitions, which are the most frequent anno- 
tations in practice, and which can be interpreted as safety properties of system runs. 
We have proposed to interpret obligations as liveness properties, and have therefore 
used a simple temporal logic to formulate these as properties of event systems. As a 
fourth category of primitives, we have considered user rights, which can be interpreted 
as elementary branching properties of systems. 

Development methods based on stepwise refinement have traditionnally been asso- 
ciated with event systems. They allow a developer to justify a system as a result of a se- 
quence of models that introduce more and more details in the representation of systems, 
as well as their correctness properties. The cornerstone of refinement is the preserva- 
tion of properties that have been established for abstract models. Standard refinement 
concepts preserve traces of models, and this ensures preservation of permissions, prohi- 
bitions, and obligations across refinements. Branching properties, including user rights, 
are not automatically preserved, and we have proposed additional conditions that rely 
on a combination of concrete-level rights and obligations. 

More experience will be necessary to evaluate whether our notions are useful and 
feasibility in practice. It would also be helpful to have an integrated tool environment 
for combining event system descriptions and access control specifications. On a more 
conceptual level, it will be interesting to study the possibility of synthesizing security 
monitors that enforce a security policy (that could possibly even vary during runtime) 
over a fixed underlying information system. 
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